---
title: Auf Astro v3 aktualisieren
description: So aktualisierst du dein Projekt auf die neueste Version von Astro.
i18nReady: true
---
import PackageManagerTabs from '~/components/tabs/PackageManagerTabs.astro'

Diese Anleitung hilft dir bei der Migration von Astro v2 zu Astro v3.

Du musst ein älteres Projekt auf v2 aktualisieren? Siehe unsere [ältere Anleitung zur Migration](/de/guides/upgrade-to/v2/).

## Astro-Aktualisierung

Aktualisiere die Astro-Version deines Projekts mit deinem Paketmanager auf die neueste Version. Wenn du Astro-Integrationen verwendest, aktualisiere bitte auch diese auf die neueste Version.

<PackageManagerTabs>
  <Fragment slot="npm">
  ```shell
  # Upgrade auf Astro v3.x
  npm install astro@latest

  # Beispiel: React- und Tailwind-Integrationen aktualisieren 
  npm install @astrojs/react@latest @astrojs/tailwind@latest
  ```
  </Fragment>
  <Fragment slot="pnpm">
  ```shell
  # Upgrade auf Astro v3.x
  pnpm add astro@latest

  # Beispiel: React- und Tailwind-Integrationen aktualisieren 
  pnpm add @astrojs/react@latest @astrojs/tailwind@latest
  ```
  </Fragment>
  <Fragment slot="yarn">
  ```shell
  # Upgrade auf Astro v3.x
  yarn add astro@latest

  # Beispiel: React- und Tailwind-Integrationen aktualisieren 
  yarn add @astrojs/react@latest @astrojs/tailwind@latest
  ```
  </Fragment>
</PackageManagerTabs>

:::note[Du musst weitermachen?]
Nach dem Aktualisieren von Astro sollten keine Änderungen an deinem Projekt nötig sein!

Falls jedoch Fehler oder unerwartetes Verhalten auftreten, schau bitte weiter unten nach, was sich geändert hat und möglicherweise in deinem Projekt aktualisiert werden muss.
:::

## Experimentelle Optionen von Astro v3.0 wurden entfernt 

Entferne die folgenden experimentellen Optionen aus `astro.config.mjs`:

```js del={5-8}
// astro.config.mjs
import { defineConfig } from 'astro/config';

export default defineConfig({
  experimental: {
    assets: true,
    viewTransitions: true,
  },
})
```

Diese Features sind jetzt standardmäßig verfügbar:

- View Transitions für animierte Seitenübergänge und persistente Astro-Inseln. Siehe die [Breaking Changes von der View Transitions API und Upgrade-Ratschläge](/de/guides/view-transitions/#upgrade-to-v30-from-v2x), wenn du diese experimentelle Option verwendet hast.
- Eine neue Bildservices-API `astro:assets` für das Verwenden von Bildern in Astro, einschließlich einer neuen `<Image />`-Komponente und der `getImage()`-Funktion. Bitte lies den detaillierten [Bilder Upgrade-Ratgeber](/de/guides/images/#upgrade-to-v30-from-v2x) **unabhängig davon, ob du diese experimentelle Option verwendet hast**, um zu sehen, wie sich dies auf dein Projekt auswirken könnte.

Lies mehr über diese zwei interessanten Features und mehr im [Astro 3.0 Blogbeitrag](https://astro.build/blog/astro-3/)!

## Astro v3.0 Breaking Changes

Astro v3.0 enthält einige wichtige Änderungen und einige veraltete Features wurden entfernt. Wenn dein Projekt nach dem Upgrade auf v3.0 nicht mehr wie erwartet funktioniert, findest du in dieser Anleitung eine Übersicht über alle Änderungen und Anweisungen, wie du deine Codebasis aktualisieren kannst.

Siehe [das Änderungsprotokoll](https://github.com/withastro/astro/blob/main/packages/astro/CHANGELOG.md) für die vollständigen Versionshinweise.

### Entfernt: Unterstützung für Node 16

Node 16 wird voraussichtlich im September 2023 sein Lebensende erreichen.

Astro v3.0 verzichtet komplett auf die Unterstützung von Node 16, damit alle Astro-Benutzer die Vorteile der moderneren Features von Node nutzen können.

#### Was soll ich tun?

Vergewissere dich, dass sowohl deine Entwicklungs- als auch deine Veröffentlichungs-Umgebung **Node `18.14.1` oder höher** verwenden.

1. Überprüfe deine lokale Version von Node mit:
    ```sh
    node -v
    ```



2. Überprüfe die Dokumentation deiner [Veröffentlichungs-Umgebung](/de/guides/deploy/), um sicherzustellen, dass sie Node 18 unterstützt.

Du kannst Node `18.14.1` für dein Astro-Projekt entweder in einer Dashboard-Konfigurationseinstellung oder in einer `.nvmrc`-Datei angeben.

```bash title=".nvmrc"
18.14.1
```
### Entfernt: Unterstützung für TypeScript 4

Die `tsconfig.json`-Voreinstellungen in Astro v2.x unterstützen TypeScript 4.x und 5.x.

Astro v3.0 aktualisiert diese Voreinstellungen und geht jetzt davon aus, dass du TypeScript 5.0 (März 2023) verwendest, oder dass dein Editor diese Version einschließt (wie z.B. VS Code 1.77).

#### Was soll ich tun?

Falls du TypeScript lokal installiert hast, aktualisiere es mindestens auf v5.0.

```bash
npm install typescript@latest --save-dev
```

### Entfernt: `@astrojs/image`

In Astro v2.x stellte Astro eine offizielle Bildintegration zur Verfügung, die Astro `<Image />`- und `<Picture />`-Komponenten einschloss.

Mit Astro v3.0 wurde diese Integration komplett entfernt. Die neue Lösung für den Umgang mit Bildern ist eine integrierte Bildservices-API: `astro:assets`.

#### Was soll ich tun?

Entferne die `@astrojs/image`-Integration aus deinem Projekt. Du musst nicht nur die Integration deinstallieren, sondern auch alle Import-Anweisungen sowie die vorhandenen `<Image />`- und `<Picture />`-Komponenten aktualisieren oder entfernen. Möglicherweise musst du auch einen bevorzugten Standardbildverarbeitungsdienst konfigurieren.

Du findest eine [Schritt-für-Schritt-Anleitung zum Entfernen der alten Bildintegration](/de/guides/images/#remove-astrojsimage) in unserer Bilder-Anleitung.

Die Migration zu `astro:assets` bringt auch einige neue Bildoptionen und Features mit sich, die du vielleicht nutzen möchtest. Bitte sieh dir den vollständigen [Upgrade-Ratgeber für Bilder in Version 3.0](/de/guides/images/#upgrade-to-v30-from-v2x) für alle Details an!

```js del={3,7}
// astro.config.mjs
import { defineConfig } from 'astro/config';
import image from '@astrojs/image';

export default defineConfig({
  integrations: [
    image(),
  ]
})
```

### Entfernt: `<Markdown />`-Komponente

In Astro v1.x wurde die `<Markdown />`-Komponente als veraltet deklariert und in ein externes Paket verschoben.

In Astro v3.0 wurde das Paket `@astrojs/markdown-component` vollständig entfernt. Die `<Markdown />`-Komponente von Astro wird nicht mehr in deinem Projekt funktionieren.

#### Was soll ich tun?

Entferne alle Verwendungen von `@astrojs/markdown-component`.

```astro del={2} title="src/components/MyAstroComponent.astro"
---
import Markdown from '@astrojs/markdown-component';
---
```

Um eine ähnliche `<Markdown />`-Komponente in deinem Code weiter zu verwenden, erwäge die Verwendung von [Community-Integrationen](https://astro.build/integrations/) wie [`astro-remote`](https://github.com/natemoo-re/astro-remote). Stelle sicher, dass du alle nötigen Änderungen an den Importen und Attributen deiner `<Markdown />`-Komponenten vornimmst, die in der Dokumentation der Integration angegeben sind.

Andernfalls entferne alle Importe der Astro-`<Markdown />`-Komponente sowie die Komponenten selbst aus deinen `.astro`-Dateien. Du musst deine Inhalte dann entweder in HTML umschreiben oder [Markdown importieren](/de/guides/markdown-content/#importieren-von-markdown), indem du `.md`-Dateien verwendest.

### Entfernt: Veraltete 1.x APIs

Mit Astro v1.x wurden unsere ursprünglichen Konfigurationseinstellungen sowie die Unterstützung von `<style global>` und `<script hoist>` als veraltet deklariert. Sie wurden jedoch weiterhin zur Abwärtskompatibilität unterstützt.

Astro v3.0 entfernt diese veralteten APIs vollständig. Stattdessen sollten die offiziell unterstützten [Konfigurationseinstellungen](/de/reference/configuration-reference/) und die moderne Syntax `<style is:global>` und `<script>` verwendet werden.

#### Was soll ich tun?

Wenn du weiterhin v1.x APIs verwendest, nutze stattdessen die neuen APIs für die jeweiligen Features:
- Veraltete Konfigurationsoptionen: Siehe [die 0.26 Migrations-Anleitung](/de/guides/upgrade-to/v1/#new-configuration-api)
- Veraltete Skript-/Style-Attributtypen: Siehe [die 0.26 Migrations-Anleitung](/de/guides/upgrade-to/v1/#new-default-script-behavior)

### Entfernt: Partielle Shims für Web-APIs in Server Code

In Astro v2.x hat Astro partielle Shims für Web-APIs wie `document` oder `localStorage` im serverseitig gerenderten Code bereitgestellt. Diese Shims waren oft unvollständig und unzuverlässig.

Astro v3.0 entfernt diese partiellen Shims vollständig. Web-APIs stehen nicht mehr im serverseitig gerenderten Code zur Verfügung.

#### Was soll ich tun?

Wenn du Web-APIs in serverseitig gerenderten Komponenten verwendest, musst du entweder die Verwendung dieser APIs bedingt machen oder [`client:only`](/de/reference/directives-reference/#clientonly) verwenden.

### Entfernt: `image` aus `astro:content` im Schema von Inhalts-Sammlungen

In Astro v2.x wurde der `image`-Export aus `astro:content` als veraltet deklariert, der für Schemas im Rahmen von Inhalts-Sammlungen verwendet wurde.

Astro v3.0 entfernt diesen Export vollständig.

#### Was soll ich tun?

Wenn du das veraltete `image()` aus `astro:content` verwendest, entferne es, da es nicht mehr existiert. Überprüfe Bilder stattdessen über [den `image`-Helfer aus `schema`](/de/guides/images/#update-content-collections-schemas):

 ```ts title="src/content/config.ts" del={1} ins={2} "({ image })"
import { defineCollection, z, image } from "astro:content";
import { defineCollection, z } from "astro:content";

 defineCollection({
   schema: ({ image }) =>
     z.object({
       image: image(),
    }),
});
```

### Entfernt: Shiki-Theme-Namen vor Version 0.14

In Astro v2.x wurden einige Shiki-Theme-Namen umbenannt, aber die ursprünglichen Namen wurden wegen der Abwärtskompatibilität beibehalten.

Astro v3.0 entfernt die ursprünglichen Namen zugunsten der umbenannten Theme-Namen.

#### Was soll ich tun?

Wenn dein Projekt eines der folgenden Themes verwendet, benenne es entsprechend seinem aktualisierten Namen um:

- `material-darker` -> `material-theme-darker`
- `material-default` -> `material-theme`
- `material-lighter` -> `material-theme-lighter`
- `material-ocean` -> `material-theme-ocean`
- `material-palenight` -> `material-theme-palenight`

### Entfernt: `class:list`-Features

In Astro v2.x verwendete die [`class:list`-Direktive](/de/reference/directives-reference/#classlist) eine benutzerdefinierte Implementierung, die von [`clsx`](https://github.com/lukeed/clsx) inspiriert war und einige zusätzliche Features wie Deduplizierung und Unterstützung für `Set` enthielt.

Astro v3.0 verwendet `clsx` jetzt direkt für `class:list`, was keine Deduplizierung oder Unterstützung für `Set`-Werte bietet.

#### Was soll ich tun?

Ersetze alle `Set`-Elemente, die der `class:list`-Direktive übergeben werden, durch ein normales `Array`.

```astro title="src/components/MyAstroComponent.astro" del={4} ins={5}
<Component class:list={[
  'a',
  'b',
  new Set(['c', 'd'])
  ['c', 'd']
]} />
```

### Entfernt: `class:list` als Prop übergeben

In Astro v2.x wurden [`class:list`-Werte](/de/reference/directives-reference/#classlist) über [`Astro.props['class:list']`](/de/reference/api-reference/#astroprops) an Komponenten übermittelt.

Astro v3.0 normalisiert `class:list`-Werte zuerst zu einem String, bevor sie über `Astro.props['class']` an Komponenten weitergegeben werden.

#### Was soll ich tun?

Entferne jeglichen Code, der den `class:list`-Prop erhält.

```astro title="src/components/MyAstroComponent.astro" del={2,3,7} ins={4,8} "classList" "'class:list': classList"
---
import { clsx } from 'clsx';
const { class: className, 'class:list': classList } = Astro.props;
const { class: className } = Astro.props;
---
<div
  class:list={[className, classList]}
  class:list={[className]}
/>
```

### Entfernt: kebab-case Umwandlung für camelCase CSS-Variablen 

In Astro v2.x wurden camelCase [CSS-Variablen](/de/guides/styling/#css-variablen), die dem `style`-Attribut übergeben wurden, sowohl in camelCase (wie geschrieben) als auch im kebab-case (für Abwärtskompatibilität beibehalten) gerendert.

Astro v3.0 entfernt die kebab-case Umwandlung für diese camelCase CSS-Variablennamen, und nur die ursprüngliche camelCase CSS-Variable wird gerendert.

```astro "my-value"
---
// src/components/MyAstroComponent.astro
const myValue = "red"
---
<!-- input -->
<div style={{ "--myValue": myValue }}></div>

<!-- output (Astro 2.x) -->
<div style="--my-value:var(--myValue);--myValue:red"></div>
<!-- output (Astro 3.0) -->
<div style="--myValue:red"></div>
```

#### Was soll ich tun?

Wenn du darauf vertraut hast, dass Astro kebab-case in deinen Styles umwandelt, aktualisiere deine bestehenden Styles zu camelCase, um fehlende Styles zu verhindern. Zum Beispiel:

```astro del={3} ins={4} title="src/components/MyAstroComponent.astro"
<style>
  div {
   color: var(--my-value);
   color: var(--myValue);
  }
</style>
```

### Entfernt: Automatisches Abflachen des Rückgabewerts von `getStaticPaths()`

In Astro v2.x wurde der Rückgabewert von [`getStaticPaths()`](/de/reference/api-reference/#getstaticpaths) automatisch abgeflacht, um es dir zu ermöglichen, ein Array aus Arrays ohne Fehler zurückzugeben.

Astro v3.0 entfernt das automatische Abflachen des Rückgabewerts von `getStaticPaths()`.

#### Was soll ich tun?

Wenn du ein Array von Arrays statt eines Arrays von Objekten zurückgibst (wie erwartet), sollten jetzt `.flatMap` und `.flat` verwendet werden, um sicherzustellen, dass du ein flaches Array zurückgibst.

Eine [Fehlermeldung, die darauf hinweist, dass der Rückgabewert von `getStaticPaths()` ein Array aus Objekten sein muss](/de/reference/errors/invalid-get-static-paths-entry/#what-went-wrong), wird bereitgestellt, wenn du deinen Code aktualisieren musst.

### Verschoben: `astro check` erfordert jetzt ein externes Paket

In Astro v2.x war [`astro check`](/de/reference/cli-reference/#astro-check) standardmäßig in Astro enthalten, und seine Abhängigkeiten waren in Astro gebündelt. Dies führte zu einem größeren Paket, unabhängig davon, ob du jemals `astro check` verwendet hast. Dies hat auch verhindert, dass du die Version von TypeScript und den Astro Language Server kontrollieren konntest.

Astro v3.0 verschiebt den Befehl `astro check` aus Astro und erfordert jetzt ein externes Paket `@astrojs/check`. Zusätzlich musst du `typescript` in deinem Projekt installieren, um den Befehl `astro check` zu verwenden.

#### Was soll ich tun?

Führe nach dem Upgrade auf Astro v3.0 den Befehl `astro check` aus und befolge die Anweisungen, um die erforderlichen Abhängigkeiten zu installieren. Alternativ kannst du `@astrojs/check` und `typescript` manuell in dein Projekt installieren.

### Veraltet: `build.excludeMiddleware` und `build.split`

In Astro v2.x wurden `build.excludeMiddleware` und `build.split` verwendet, um zu ändern, wie bestimmte Dateien beim Verwenden eines Adapters im SSR-Modus ausgegeben wurden.

Astro v3.0 ersetzt diese Erzeugungs-Konfigurationsoptionen durch neue [SSR-Adapter-Konfigurationsoptionen](/de/guides/integrations-guide/#offizielle-integrationen), um die gleichen Aufgaben zu erledigen: `edgeMiddleware` und `functionPerRoute`.

#### Was soll ich tun?

Aktualisiere die Astro-Konfigurationsdatei, um die neuen Optionen nun direkt **in der Adapter-Konfiguration** zu verwenden.

```js title="astro.config.mjs" del={5-7} ins={9}
import { defineConfig } from "astro/config";
import vercel from "@astrojs/vercel/serverless";

export default defineConfig({
    build: {
      excludeMiddleware: true
    },
    adapter: vercel({
      edgeMiddleware: true
    }),
});
```

```js title="astro.config.mjs" del={5-7} ins={9}
import { defineConfig } from "astro/config";
import netlify from "@astrojs/netlify/functions";

export default defineConfig({
     build: {
        split: true
     },
     adapter: netlify({
        functionPerRoute: true
     }),
});
```

### Veraltet: `markdown.drafts`

In Astro v2.x ermöglichte die Konfiguration `markdown.drafts` das Vorhandensein von Entwürfen für Seiten, die im Dev-Server verfügbar waren, aber nicht für die Produktion erzeugt wurden.

Astro v3.0 deklariert dieses Feature als veraltet und bevorzugt die Verwendung von Inhalts-Sammlungen zum Umgang mit Entwurfsseiten durch manuelle Filterung, was mehr Kontrolle über das Feature ermöglicht.

#### Was soll ich tun?

Um weiterhin einige Seiten in deinem Projekt als Entwürfe zu kennzeichnen, [verwende stattdessen Inhalts-Sammlungen](/de/guides/content-collections/#migrating-from-file-based-routing) und [filtere Seiten manuell aus](/de/guides/content-collections/#filtering-collection-queries), indem du die `draft: true`-Frontmatter-Eigenschaft verwendest.

### Veraltet: Rückgabe eines einfachen Objekts an Endpunkten

In Astro v2.x konnten Endpunkte ein einfaches Objekt zurückgeben, das in eine JSON-Antwort umgewandelt wurde.

Astro v3.0 deklariert dieses Verhalten als veraltet und bevorzugt die direkte Rückgabe eines `Response`-Objekts.

#### Was soll ich tun?

Aktualisiere deine Endpunkte, um direkt ein `Response`-Objekt zurückzugeben.

```ts title="endpoint.json.ts" del={2} ins={3}
export async function GET() {
  return { body: { "title": "Bob's blog" }};
  return new Response(JSON.stringify({ "title": "Bob's blog" }));
}
```

Wenn du wirklich das vorherige Format beibehalten musst, kannst du das `ResponseWithEncoding`-Objekt verwenden, aber beachte, dass es in Zukunft veraltet sein wird.

```ts title="endpoint.json.ts" del={2} ins={3}
export async function GET() {
  return { body: { "title": "Bob's blog" } };
  return new ResponseWithEncoding({ body: { "title": "Bob's blog" }});
}
```

### Standardwert geändert: `verbatimModuleSyntax` in tsconfig.json-Voreinstellungen

In Astro v2.x war die Einstellung [`verbatimModuleSyntax`](https://www.typescriptlang.org/tsconfig#verbatimModuleSyntax) standardmäßig deaktiviert, wobei ihr TypeScript 4.x-Äquivalent `importsNotUsedAsValues` in der `strict`-Voreinstellung aktiviert war.

In Astro v3.0 ist `verbatimModuleSyntax` in jeder Voreinstellung aktiviert.

#### Was soll ich tun?

Diese Option erfordert, dass Typen mit der Syntax `import type` importiert werden.

```astro title="src/components/MyAstroComponent.astro" "type"
---
import { type CollectionEntry, getEntry } from "astro:content";
---
```

Wir empfehlen, diese Option aktiviert zu lassen und deine Typen ordnungsgemäß mit `type` zu importieren (wie oben gezeigt). Sollte es zu Problemen kommen, kannst du die Option deaktivieren, indem du `verbatimModuleSyntax: false` in deiner `tsconfig.json`-Datei setzt.

```json title="tsconfig.json" "false"
{
  "compilerOptions": {
    "verbatimModuleSyntax": false
  }
}
```

### Standardwert geändert: Port `3000`

In Astro v2.x lief Astro standardmäßig auf Port `3000`.

Astro v3.0 ändert den [Standardport](/de/reference/cli-reference/#--port-number) zu `4321`. 🚀

#### Was soll ich tun?

Aktualisiere alle vorhandenen Verweise auf `localhost:3000`, zum Beispiel in Tests oder in deiner `README`, um den neuen Port `localhost:4321` widerzuspiegeln.

### Standardwert geändert: import.meta.env.BASE_URL `trailingSlash`

In Astro v2.x hat `import.meta.env.BASE_URL` standardmäßig deine [`base`](/de/reference/configuration-reference/#base)-Einstellung in Kombination mit einem [trailingSlash](/de/reference/configuration-reference/#trailingslash) um ein Schrägstrichsuffix erweitert. `trailingSlash: "ignore"` hat ebenfalls ein Schrägstrichsuffix hinzugefügt.

Astro v3.0 fügt `import.meta.env.BASE_URL` standardmäßig nicht mehr mit einem Schrägstrichsuffix hinzu, auch nicht wenn `trailingSlash: "ignore"` festgelegt ist. (Das bestehende Verhalten von `base` in Kombination mit `trailingSlash: "always"` oder `trailingSlash: "never"` bleibt unverändert.)

#### Was soll ich tun?

Wenn deine `base` bereits ein Schrägstrichsuffix hat, ist keine Änderung erforderlich.

Wenn deine `base` kein Schrägstrichsuffix hat, füge einen hinzu, wenn du das vorherige Standardverhalten (oder `trailingSlash: "ignore"`) beibehalten möchtest:

```js title="astro.config.mjs" del={4} ins={5}
import { defineConfig } from "astro/config";

export default defineConfig({
  base: 'my-base',
  base: 'my-base/',
});
```

### Standardwert geändert: `compressHTML`

In Astro v2.x hat Astro dein ausgegebenes HTML nur komprimiert, wenn [`compressHTML`](/de/reference/configuration-reference/#compresshtml) explizit auf `true` gesetzt war. Der Standardwert war `false`.

Astro v3.0 komprimiert jetzt standardmäßig das ausgegebene HTML.

#### Was soll ich tun?

Du kannst jetzt `compressHTML: true` aus deiner Konfiguration entfernen, da dies das neue Standardverhalten ist.

```js title="astro.config.mjs" del={4}
import { defineConfig } from "astro/config";

export default defineConfig({
  compressHTML: true
})
```

Du musst nun `compressHTML: false` setzen, um die HTML-Komprimierung nicht zu verwenden.

### Standardwert geändert: `scopedStyleStrategy`

In Astro v2.x war der Standardwert von [`scopedStyleStrategy`](/de/reference/configuration-reference/#scopedstylestrategy) `"where"`.

Astro v3.0 führt einen neuen Standardwert ein: `"attribute"`. Standardmäßig werden Styles jetzt mit `data-*`-Attributen angewendet.

#### Was soll ich tun?

Um das aktuelle [Style-Scoping](/de/guides/styling/#scoped-styles) deines Projekts beizubehalten, aktualisiere die Konfigurationsdatei auf den vorherigen Standardwert:


```js title="astro.config.mjs" ins={4}
import { defineConfig } from "astro/config";

export default defineConfig({
  scopedStyleStrategy: "where"
})
```

### Standardwert geändert: `inlineStyleSheets`

In Astro v2.x wurden standardmäßig alle Projekt-Styles als Link-Tags gesendet. Du konntest die Option [`build.inlineStylesheets`](/de/reference/configuration-reference/#buildinlinestylesheets) verwenden, um Styles stattdessen direkt in `<style>`-Tags einzubetten: Mit der Einstellung `"always"` wurden alle Styles eingebettet, und mit `"auto"` nur Styles unterhalb einer bestimmten Größe. Die Standardvoreinstellung war `"never"`.

Astro v3.0 ändert den Standardwert von `inlineStylesheets` zu `"auto"`. Stylesheets kleiner als `ViteConfig.build.assetsInlineLimit` (Standard: 4 KB) werden standardmäßig eingefügt. Andernfalls werden Projekt-Styles in externen Stylesheets gesendet.

#### Was soll ich tun?
Wenn du das aktuelle Verhalten deines Projekts beibehalten möchtest, setze `build.inlineStylesheets` auf den vorherigen Standardwert `"never"`:


```js title="astro.config.mjs" ins={4-6}
import { defineConfig } from "astro/config";

export default defineConfig({
	 build: {
    inlineStylesheets: "never"
  }
})
```

### Standardwert geändert: Bilderdienst

In Astro v2.x war Squoosh der [Standard-Bildverarbeitungsdienst](/de/guides/images/#default-image-service).

Astro v3.0 enthält jetzt standardmäßig Sharp als Bildverarbeitungsdienst und bietet stattdessen eine Konfigurationsoption, um Squoosh zu verwenden.

#### Was soll ich tun?

:::note
Bei Verwendung eines [strikten Paketmanagers](https://pnpm.io/pnpm-vs-npm#npms-flat-tree) wie `pnpm` musst du möglicherweise Sharp manuell in dein Projekt installieren, obwohl es eine Abhängigkeit von Astro ist:

```bash
pnpm add sharp
```
:::

Wenn du Squoosh weiterhin für die Verarbeitung deiner Bilder verwenden möchtest, aktualisiere deine Konfiguration wie folgt:

```ts title="astro.config.mjs" ins={4-6}
import { defineConfig, squooshImageService } from "astro/config";

export default defineConfig({
  image: {
    service: squooshImageService(),
  }
})
```

### Geändert: Groß- und Kleinschreibung der HTTP-Anforderungsmethoden

In Astro v2.x wurden [HTTP-Anforderungsmethoden](/de/guides/endpoints/#http-methoden) mit Kleinbuchstaben verwendet: `get`, `post`, `put`, `all` und `del`.

Astro v3.0 verwendet Großbuchstaben, einschließlich `DELETE` anstelle von `del`.

#### Was soll ich tun?

Benenne alle Funktionen in ihre Großbuchstaben-Äquivalente um:

- `get` to `GET`
- `post` to `POST`
- `put` to `PUT`
- `all` to `ALL`
- `del` to `DELETE`

```js title="endpoint.ts" del={1} ins={2}
export function get() {
export function GET() {
    return new Response(JSON.stringify({ "title": "Bob's blog" }));
}
```

### Geändert: Konfiguration für mehrere JSX-Frameworks

In Astro v2.x konntest du [mehrere JSX-Framework-Integrationen](/de/guides/integrations-guide/#offizielle-integrationen) (React, Solid, Preact) im selben Projekt verwenden, ohne angeben zu müssen, welche Dateien zu welchem Framework gehören.

Astro v3.0 erfordert nun, dass du angibst, welches Framework für deine Dateien verwendet werden soll, indem du neue `include`- und `exclude`-Integrationskonfigurationsoptionen verwendest, wenn du mehrere JSX-Framework-Integrationen installiert hast. Dies ermöglicht es Astro, die Verwendung eines einzigen Frameworks besser zu unterstützen, sowie fortgeschrittene Funktionen wie React Fast Refresh.

#### Was soll ich tun?

Wenn du mehrere JSX-Frameworks im selben Projekt verwendest, setze `include` (und optional `exclude`) auf ein Array von Dateien und/oder Ordnern. Wildcards können verwendet werden, um mehrere Dateipfade einzuschließen.

Wir empfehlen, gemeinsame Framework-Komponenten im selben Ordner zu speichern (z.B. `/components/react/` und `/components/solid/`), um die Angabe deiner Includes zu erleichtern, aber dies ist nicht erforderlich:

```js ins={13,16,19}
import { defineConfig } from 'astro/config';
import preact from '@astrojs/preact';
import react from '@astrojs/react';
import svelte from '@astrojs/svelte';
import vue from '@astrojs/vue';
import solid from '@astrojs/solid-js';

export default defineConfig({
  // Aktiviere viele Frameworks, um verschiedene Arten von Komponenten zu unterstützen.
  // `include` ist nicht erforderlich, wenn du nur ein Framework verwendest!
  integrations: [
    preact({
      include: ['**/preact/*']
    }),
    react({
      include: ['**/react/*']
    }),
    solid({
      include: ['**/solid/*'],
    }),
  ]
});
```

### Geändert: `Astro.cookies.get(key)` kann `undefined` zurückgeben

In Astro v2.x hat [`Astro.cookies.get(key)`](/de/reference/api-reference/#astrocookies) immer ein [`AstroCookie`-Objekt](/de/reference/api-reference/#astrocookie) zurückgegeben, auch wenn kein Cookie existierte. Um auf dessen Existenz zu prüfen, musstest du `Astro.cookies.has(key)` verwenden.

Astro v3.0 gibt für `Astro.cookies.get(key)` nun `undefined` zurück, wenn kein Cookie existiert.

#### Was soll ich tun?

Diese Änderung wird keinen Code unbrauchbar machen, der auf die Existenz des `Astro.cookie`-Objekts überprüft, bevor `Astro.cookies.get(key)` verwendet wird, ist jedoch jetzt nicht mehr erforderlich.

Du kannst ohne Probleme jeglichen Code entfernen, der `has()` verwendet, um zu überprüfen, ob der Wert von `Astro.cookies` `undefined` ist:

```js del={1-3} ins={5-7}
if (Astro.cookies.has(id)) {
  const id = Astro.cookies.get(id)!;
}

const id = Astro.cookies.get(id);
if (id) {
}
```

### Geändert: Programmatisches Ausführen der Astro Kommandozeilen&shy;schnittstelle (CLI)

In Astro v2.x exportierte und startete der Eintrittspunkt des Pakets `"astro"` die Astro CLI direkt. Es wird nicht empfohlen, Astro auf diese Weise in der Praxis auszuführen.

Astro v3.0 entfernt die CLI aus dem Eintrittspunkt und exportiert einen neuen Satz experimenteller JavaScript-APIs, einschließlich `dev()`, `build()`, `preview()` und `sync()`.

#### Was soll ich tun?

Um die Astro Kommandozeilenschnittstelle [programmatisch auszuführen](/de/reference/cli-reference/#advanced-apis-experimental), verwende die neuen experimentellen JavaScript-APIs:


```js
import { dev, build } from "astro";

// Starte den Astro-Entwicklungsserver
const devServer = await dev();
await devServer.stop();

// Erzeuge dein Astro-Projekt
await build();
```

### Geändert: Pfade für den Export von internen Astro-API-Einstiegspunkten

In Astro v2.x konntest du interne Astro-APIs aus `astro/internal/*` und `astro/runtime/server/*` importieren.

Astro v3.0 entfernt die beiden Einstiegspunkte zugunsten des vorhandenen Einstiegspunkts `astro/runtime/*`. Zusätzlich wurde ein neuer Export `astro/compiler-runtime` für compiler-spezifischen Laufzeitcode hinzugefügt.

#### Was soll ich tun?

Diese sind Einstiegspunkte für Astros interne API und sollten sich nicht auf dein Projekt auswirken. Aber wenn du diese Einstiegspunkte verwendest, aktualisiere sie wie unten gezeigt:


```js del={1,4,10} ins={2,5,11}
import 'astro/internal/index.js';
import 'astro/runtime/server/index.js';

import 'astro/server/index.js';
import 'astro/runtime/server/index.js';
```

```js ins={5} del={4}
import { transform } from '@astrojs/compiler';

const result = await transform(source, {
  internalURL: 'astro/runtime/server/index.js',
  internalURL: 'astro/compiler-runtime',
  // ...
});
```

## Community-Ressourcen

Du kennst eine gute Ressource für Astro v3.0? [Bearbeite diese Seite](https://github.com/withastro/docs/edit/main/src/content/docs/en/guides/upgrade-to/v3.mdx) und füge unten einen Link hinzu!

## Bekannte Probleme

Es gibt derzeit keine bekannten Probleme.
